home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / program / rcs5ap1b.lzh / CI.1LP next >
Text File  |  1991-01-30  |  12KB  |  331 lines
  1.  
  2.  
  3.  
  4. CI(1)                  Programmer's Manual                  CI(1)
  5.  
  6.  
  7.  
  8. NAME
  9.      ci - check in RCS revisions
  10.  
  11. SYNOPSIS
  12.      ci [_✓o_✓p_✓t_✓i_✓o_✓n_✓s] _✓f_✓i_✓l_✓e ...
  13.  
  14. DESCRIPTION
  15.      ci stores new revisions into RCS files.  Each file name end-
  16.      ing in ,v is taken to be an RCS file.  All others are
  17.      assumed to be working files containing new revisions.  ci
  18.      deposits the contents of each working file into the
  19.      corresponding RCS file.  If only a working file is given, ci
  20.      tries to find the corresponding RCS file in an RCS subdirec-
  21.      tory and then in the working file's directory.  For more
  22.      details, see FILE NAMING below.
  23.  
  24.      For ci to work, the caller's login must be on the access
  25.      list, except if the access list is empty or the caller is
  26.      the superuser or the owner of the file.  To append a new
  27.      revision to an existing branch, the tip revision on that
  28.      branch must be locked by the caller.  Otherwise, only a new
  29.      branch can be created.  This restriction is not enforced for
  30.      the owner of the file if non-strict locking is used (see
  31.      rcs(1)).  A lock held by someone else may be broken with the
  32.      rcs command.
  33.  
  34.      Normally, ci checks whether the revision to be deposited is
  35.      different from the preceding one.  If it is not different,
  36.      ci aborts the deposit, asking beforehand if possible.  A
  37.      deposit can be forced with the -f option.
  38.  
  39.      For each revision deposited, ci prompts for a log message.
  40.      The log message should summarize the change and must be ter-
  41.      minated by end-of-file or by a line containing . by itself.
  42.      If several files are checked in ci asks whether to reuse the
  43.      previous log message.  If the standard input is not a termi-
  44.      nal, ci suppresses the prompt and uses the same log message
  45.      for all files.  See also -m.
  46.  
  47.      The number of the deposited revision can be given by any of
  48.      the options -f, -I, -k, -l, -q, -r, or -u.
  49.  
  50.      If the RCS file does not exist, ci creates it and deposits
  51.      the contents of the working file as the initial revision
  52.      (default number: 1.1).  The access list is initialized to
  53.      empty.  Instead of the log message, ci requests descriptive
  54.      text (see -t below).
  55.  
  56. OPTIONS
  57.      -r[_✓r_✓e_✓v]
  58.           assigns the revision number _✓r_✓e_✓v to the checked-in revi-
  59.           sion, releases the corresponding lock, and deletes the
  60.  
  61.  
  62.  
  63. Printed 1/29/91            1990/12/04                           1
  64.  
  65.  
  66.  
  67.  
  68.  
  69.  
  70. CI(1)                  Programmer's Manual                  CI(1)
  71.  
  72.  
  73.  
  74.           working file.  This is the default.  _✓r_✓e_✓v may be sym-
  75.           bolic, numeric, or mixed.
  76.  
  77.           If _✓r_✓e_✓v is a revision number, it must be higher than the
  78.           latest one on the branch to which _✓r_✓e_✓v belongs, or must
  79.           start a new branch.
  80.  
  81.           If _✓r_✓e_✓v is a branch rather than a revision number, the
  82.           new revision is appended to that branch.  The level
  83.           number is obtained by incrementing the tip revision
  84.           number of that branch.  If _✓r_✓e_✓v indicates a non-existing
  85.           branch, that branch is created with the initial revi-
  86.           sion numbered _✓r_✓e_✓v.1.
  87.  
  88.           If _✓r_✓e_✓v is omitted, ci tries to derive the new revision
  89.           number from the caller's last lock.  If the caller has
  90.           locked the tip revision of a branch, the new revision
  91.           is appended to that branch.  The new revision number is
  92.           obtained by incrementing the tip revision number.  If
  93.           the caller locked a non-tip revision, a new branch is
  94.           started at that revision by incrementing the highest
  95.           branch number at that revision.  The default initial
  96.           branch and level numbers are 1.
  97.  
  98.           If _✓r_✓e_✓v is omitted and the caller has no lock, but owns
  99.           the file and locking is not set to _✓s_✓t_✓r_✓i_✓c_✓t, then the
  100.           revision is appended to the default branch (normally
  101.           the trunk; see the -b option of rcs(1)).
  102.  
  103.           Exception: On the trunk, revisions can be appended to
  104.           the end, but not inserted.
  105.  
  106.      -f[_✓r_✓e_✓v]
  107.           forces a deposit; the new revision is deposited even it
  108.           is not different from the preceding one.
  109.  
  110.      -k[_✓r_✓e_✓v]
  111.           searches the working file for keyword values to deter-
  112.           mine its revision number, creation date, state, and
  113.           author (see co(1)), and assigns these values to the
  114.           deposited revision, rather than computing them locally.
  115.           It also generates a default login message noting the
  116.           login of the caller and the actual checkin date.  This
  117.           option is useful for software distribution.  A revision
  118.           that is sent to several sites should be checked in with
  119.           the -k option at these sites to preserve the original
  120.           number, date, author, and state.  The extracted keyword
  121.           values and the default log message may be overridden
  122.           with the options -d, -m, -s, -w, and any option that
  123.           carries a revision number.
  124.  
  125.      -l[_✓r_✓e_✓v]
  126.  
  127.  
  128.  
  129. Printed 1/29/91            1990/12/04                           2
  130.  
  131.  
  132.  
  133.  
  134.  
  135.  
  136. CI(1)                  Programmer's Manual                  CI(1)
  137.  
  138.  
  139.  
  140.           works like -r, except it performs an additional co -l
  141.           for the deposited revision.  Thus, the deposited revi-
  142.           sion is immediately checked out again and locked.  This
  143.           is useful for saving a revision although one wants to
  144.           continue editing it after the checkin.
  145.  
  146.      -u[_✓r_✓e_✓v]
  147.           works like -l, except that the deposited revision is
  148.           not locked.  This lets one read the working file
  149.           immediately after checkin.
  150.  
  151.      -q[_✓r_✓e_✓v]
  152.           quiet mode; diagnostic output is not printed.  A revi-
  153.           sion that is not different from the preceding one is
  154.           not deposited, unless -f is given.
  155.  
  156.      -I[_✓r_✓e_✓v]
  157.           interactive mode; the user is prompted and questioned
  158.           even if the standard input is not a terminal.
  159.  
  160.      -d[_✓d_✓a_✓t_✓e]
  161.           uses _✓d_✓a_✓t_✓e for the checkin date and time.  The _✓d_✓a_✓t_✓e is
  162.           specified in free format as explained in co(1).  This
  163.           is useful for lying about the checkin date, and for -k
  164.           if no date is available.  If _✓d_✓a_✓t_✓e is empty, the working
  165.           file's time of last modification is used.
  166.  
  167.      -m_✓m_✓s_✓g
  168.           uses the string _✓m_✓s_✓g as the log message for all revi-
  169.           sions checked in.
  170.  
  171.      -n_✓n_✓a_✓m_✓e
  172.           assigns the symbolic name _✓n_✓a_✓m_✓e to the number of the
  173.           checked-in revision.  ci prints an error message if
  174.           _✓n_✓a_✓m_✓e is already assigned to another number.
  175.  
  176.      -N_✓n_✓a_✓m_✓e
  177.           same as -n, except that it overrides a previous assign-
  178.           ment of _✓n_✓a_✓m_✓e.
  179.  
  180.      -s_✓s_✓t_✓a_✓t_✓e
  181.           sets the state of the checked-in revision to the iden-
  182.           tifier _✓s_✓t_✓a_✓t_✓e.  The default state is Exp.
  183.  
  184.      -t_✓f_✓i_✓l_✓e
  185.           writes descriptive text from the contents of the named
  186.           _✓f_✓i_✓l_✓e into the RCS file, deleting the existing text.
  187.           The _✓f_✓i_✓l_✓e name may not begin with -.
  188.  
  189.      -t-_✓s_✓t_✓r_✓i_✓n_✓g
  190.           Write descriptive text from the _✓s_✓t_✓r_✓i_✓n_✓g into the RCS
  191.           file, deleting the existing text.
  192.  
  193.  
  194.  
  195. Printed 1/29/91            1990/12/04                           3
  196.  
  197.  
  198.  
  199.  
  200.  
  201.  
  202. CI(1)                  Programmer's Manual                  CI(1)
  203.  
  204.  
  205.  
  206.           The -t option, in both its forms, has effect only dur-
  207.           ing an initial checkin; it is silently ignored other-
  208.           wise.
  209.  
  210.           During the initial checkin, if -t is not given, ci
  211.           obtains the text from standard input, terminated by
  212.           end-of-file or by a line containing . by itself.  The
  213.           user is prompted for the text if interaction is possi-
  214.           ble; see -I.
  215.  
  216.           For backward